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DETAILED ACTION 

Continued Examination Under 37 CFR 1.114 

1 . A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1 .17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.1 14, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.1 14. Applicant's submission filed on 22 April 2010 has been entered. 

2. Claims 20-39 have been presented for examination. 

3. Claims 1-19 and 40 have been cancelled as per applicant's amendment. 

Response to Arguments 

4. Applicant's arguments with respect to the rejections made under 35 USC § 1 12 filed 22 

23 March 2010 have been fully considered but they are not persuasive. The applicant argues that 

the specification clearly defines the term at page 29, lines 7-9 and Figure 4. "The meaning of 

every term used in any of the claims should be apparent from the descriptive portion of the 

specification with clear disclosure as to its import . . . ." M.P.E.P. § 608.01(o). Page 29, lines 7-9 

of the specification recites: 

[The TS payload part P contains the data that have been] divided and 
encapsulated in accordance with the first protocol. The TS header HTS of each 
TS packet is composed of a packet ID (PID part and a scramble control part as 
[depicted in Fig. 4.] 

Figure 4 provides no more guidance as to how the applicant intends to use the term "transport 
stream headers." Therefore, the applicant has failed to put one reasonably skilled in the art on 
notice that the applicant intended to redefine the claim term "transport stream headers." 
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5. Applicant's arguments with respect to claims 20-39 have been considered but are moot in 
view of the new grounds of rejection set forth below. 

Claim Rejections - 35 USC § 112 

6. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

7. Claims 20-39 are rejected under 35 U.S.C. 1 12, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. Where applicant acts as his or her own lexicographer to specifically define a term 
of a claim contrary to its ordinary meaning, the written description must clearly redefine the 
claim term and set forth the uncommon definition so as to put one reasonably skilled in the art on 
notice that the applicant intended to so redefine that claim term. Process Control Corp. v. 
HydReclaim Corp., 190 F.3d 1350, 1357, 52 USPQ2d 1029, 1033 (Fed. Cir. 1999). The term 
"transport stream headers" in claims 20-39 is used by the claim to mean "a physical layer header 
(in accordance with the OSI model)," while the accepted meaning is "transport layer header," 
such as an IP header. The term is indefinite because the specification does not clearly redefine 
the term. 

Claim Rejections - 35 USC § 103 

8. The text of those sections of Title 35, U.S. Code not included in this action can be found 
in a prior Office action. 

9. Claims 20-24, 26-34, and 36-39 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over U.S. Patent No. 6,163,843 to Inoue et al., hereinafter Inoue, in view of U.S. 
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Patent No. 6,266,335 Bl to Bhaskaran et al., hereinafter Bhaskaran, and in further view of U.S. 
Patent No. 6,385,657 Bl to Willis et al, hereinafter Willis. 

10. As per claim 20, Inoue discloses a data transmission controlling method for 
controlling transmission of data from data transmitting means to data receiving means over 
communication channels and for causing said data transmitting means to encrypt data and 
transmit the encrypted data to said data receiving means over said communication channels, said 
data transmission controlling method comprising the steps of: 

encapsulating the data to be transmitted in multiplexed fashion and having a destination 
address in accordance with a first protocol to create a section wherein the section is creates based 
upon the destination address (Figures 12A-12D [Inner Protocols (IP/UDP/TCP)], column 12, 
lines 45-53, i.e. the inner protocols are encapsulated in an IP packet, IP header has a destination 
address); 

encrypting the section resulting from the encapsulation (Figure 12C [encrypted 
information], column 12, lines 45-53, i.e. as discussed below Section 3.2 of RFC 1825 describes 
encrypting the encapsulated data); 

dividing the encrypted supplemented section into a plurality of payloads in accordance 
with a second protocol (Figures 12A-12D [leftmost IPv4 Header], column 12, lines 45-53, i.e. as 
discussed below Section 3.2 of RFC 1825 describes encapsulating the encrypted encapsulated 
data in a new cleartext IP header; RFC 1825 discusses fragmentation at Section 3.1; RFC 1826 
discloses fragmentation in at least Section 1.1; RFC 1827 mentions fragmentation in Section 4); 
and 
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adding transport stream headers to each payload to form packets for transmission 
(Figures 12A-12D [Inner Protocols (IP/UDP/TCP)], column 12, lines 45-53, i.e. the inner 
protocols are encapsulated in an IP packet, which includes an IP header); 

wherein the first encapsulating step is done before the encrypting step (column 12, lines 
45-53, i.e. as discussed below Section 3.2 of RFC 1825 describes encapsulating prior to 
encrypting the encapsulated data) and the first protocol pads a portion of 0 to 63 bits (Figures 
12B and 12C [Authentication Header (AH)], column 12, lines 45-53, i.e. RFC 1826 is 
incorporated into Inoue at column 12, line 47. RFC 1826 discloses at Section 3.2 (printed pages 
5 and 6 of 13) that many implementations of the authentication header require padding up to 64 
bits). Inoue discloses the use of the IP security standard and refers to RFC documents 1825- 
1829. Printed pages 8 and 9 (of 21) of RFC 1825 (Section 3.2) provides more information 
regarding encapsulating an entire IP datagram or upper-layer protocols and encrypting that 
information before encapsulating it in a new cleartext IP header. Applicant is also directed to 
RFC documents 1826 (for information regarding the Authentication Header, abbreviated as AH 
in Inoue) and 1827 (for information regarding the Encapsulating Security Payload, abbreviated 
as ESP in Inoue) for information regarding encapsulation, encryption and padding. See MPEP 
§ 2131.01 for the discussion on the use of multiple references. 

1 1 . Inoue does not teach supplementing the encrypted section with a section header and a 
section trailer, wherein the section header included a MAC (media access control) header and 
wherein the padding is filled with a corresponding "1" as a suffix to the data. 

12. It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to fill the padding data with 1 's and add it as a suffix to the data. Since it is padding 
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data and is there to act as filler, it is irrelevant what data is actually used to fill the padding 
information. Inoue and the RFC documents disclose the Authentication Header as being in the 
middle of the datagram (see Figures 12B and 12C of Inoue). Relocating the Authentication 
header to the rear of the datagram, thereby making the padding data suffix information to the 
entire datagram, would have required only routine skill in the art since it has been held that the 
mere relocation of a part is not patently distinguishable if it has no bearing on the operation of 
the device. See MPEP § 2144.04; see In reJapikse, 181 F.2d 1019, 86 USPQ 70 (CCPA 1950). 

13. Bhaskaran discloses an encrypted payload (column 2, lines 42-65) that is book-ended by 
a header that includes a MAC header (Figure 3A [clement 320]) and trailer (Figure 3A [element 
360], 3B [elements 320, 380, 390], column 6, lines 26-63). 

14. Bhaskaran also teaches adding transport stream headers to each payload to form packets 
for transmission (Figure 3 A [element 310], column 6, lines 26-49); 

15. It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to supplement the encrypted data section with a section header and trailer, since 
Bhaskaran states at column 6, lines 40-49 that they would eliminate the need to recomputed the 
checksum for every packet, thereby making the network throughput better. Furthermore, IPsec 
can be deployed transparently and without fear of communications being interrupted. 

16. Inoue and Bhaskaran do not teach transmitting the packets over satellite links. 

17. Willis teaches transmitting packets that have been secured using IPSec over a satellite 
link (Figures 1, 9, column 4, lines 16-25, column 15, lines 33-46, column 16, lines 25-51). 

18. It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to transmit IPsec packets over a satellite link, since Willis states at column 4, lines 23- 
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34 that the use of IPsec packets over a satellite link greatly improves the performance of 
transmission while reducing the cost and being secure. 

19. Regarding claims 21 and 22, Inoue discloses wherein said encapsulating in accordance 
with said first protocol supplements a real data part including said data to be transmitted to said 
data receiving means with an additional information part associated with said real data part and 
wherein said additional information part includes destination address information identifying the 
data receiving means authorized to receive data included in said real data part (Figure 12C [IPv4 
header, middle of the packet], IPv4 headers include information such as source and destination 
address information). 

20. Concerning claim 23, Inoue discloses wherein said destination address information is an 
individual (Figure 12C [IPv4 header, middle of the packet], IPv4 headers include information 
such as source and destination address information) or group destination address information 
(column 12, line 48, i.e. RFC 1825). Section 5.2 of RFC 1825 discloses using IPSec in a 
multicast type setting, thereby disclosing the group destination address information. 

21 . Concerning claim 24, Inoue discloses wherein said data transmitting means possesses 
session keys corresponding to said destination address information, said session keys being used 
by said data transmitting means to encrypt information and data and by said receiving means to 
decrypt the encrypted information and data received; and wherein said data transmitting means 
transmits in advance said session keys to the data receiving means authorized to receive the 
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transmitted information and data in accordance with said destination address information 
(column 12, line 48, i.e. RFC 1825). Section 4.4 of RFC 1825 discloses the use of different 
session keys for each client on the network. 

22. Concerning claim 26, Inoue discloses wherein said session keys are transmitted over a 
communication channel permitting from said data transmitting means to said data receiving 
means or bidirectional communication therebetween (column 12, line 48, i.e. RFC 1825). 
Section 4.4 of RFC 1825 discloses how the different session keys are distributed. 

23. With regards to claim 27, Inoue discloses wherein said encapsulating in accordance with 
said first protocol uniquely determines how said destination address information attached to said 
real data part is stored into said additional information part (column 12, lines 48, i.e. Section 3.2 
of RFC 1825 describes encapsulating the data, see also RFC 1827), said encrypting step further 
encrypting said real data part using a master key specific to the data receiving means 
corresponding to said destination address information (column 12, line 48, i.e. RFC 1825). 
Section 4.4 of RFC 1825 discloses the use of different session keys for each client on the 
network. 

24. Concerning claim 28, Inoue discloses wherein said additional information part provides a 
48-bit space in which to accommodate said destination address information (Figures 12A-12D 
[IPv4 headers, Authentication Header]). 
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25. With regards to claim 29, Inoue wherein the communication channel is in a broadcast 
data transmission system, including a satellite broadcast system, and said encapsulating in 
accordance with said first protocol uniquely encapsulates the data to be transmitted to said data 
receiving means in accordance with either the Internet protocol (Figures 12A-12D [leftmost IPv4 
Header], column 12, lines 45-53) or the Ethernet protocol. 

26. Regarding claims 30-31, 36-37, Inoue discloses wherein said data receiving means is 
constituted as a bridge or an IP router (Figures 1 [blocks 4a, 4c], 2 [blocks 4a, 4b, 4c], 3, 6 
[blocks 4a, 4b], column 7, lines 21-38). 

27. As per claim 32, Inoue discloses a data transmission controlling method for controlling 
the transmission of data from data transmitting means to data receiving means over 
communication channels and for causing said data transmitting means to encrypt data and 
transmit the encrypted data to said data receiving means over said communication channels, said 
data transmission controlling method comprising the steps of: 

encapsulating the data to be transmitted in multiplexed fashion in accordance with a first 
protocol to form a section therein creating a section based upon the destination address (Figures 
12A-12D [Inner Protocols (IP/UDP/TCP)], column 12, lines 45-53, i.e. the inner protocols are 
encapsulated in an IP packet, IP headers include destination address information), wherein the 
first protocol pads a portion of 0 to 63 bits (Figures 12B and 12C [Authentication Header (AH)], 
column 12, lines 45-53, i.e. RFC 1826 is incorporated into Inoue at column 12, line 47. RFC 
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1826 discloses at Section 3.2 (printed pages 5 and 6 of 13) that many implementations of the 
authentication header require padding up to 64 bits); 

encrypting the section using an encryption key (Figure 12C [encrypted information], 
column 12, lines 45-53, i.e. Section 3.2 of RFC 1825 describes encrypting the encapsulated 
data); 

supplementing the encrypted section with encryption key information about said 
encryption key (Figure 12C [Key Information Header (Key)]); 

dividing the encrypted supplemented section into a plurality of payloads in accordance 
with a second protocol (Figures 12A-12D [leftmost IPv4 Header], column 12, lines 45-53, i.e. as 
discussed below Section 3.2 of RFC 1825 describes encapsulating the encrypted encapsulated 
data in a new cleartext IP header; RFC 1825 discusses fragmentation at Section 3.1; RFC 1826 
discloses fragmentation in at least Section 1.1; RFC 1827 mentions fragmentation in Section 4); 

adding transport stream headers to each pay load to form a packet (Figures 12A-12D 
[Inner Protocols (IP/UDP/TCP)], column 12, lines 45-53, i.e. the inner protocols are 
encapsulated in an IP packet, which includes an IP header); 

transmitting said packets from said data transmitting means to said data receiving means 
(Figure 6, column 2, lines 57-64, column 6, line 64 to column 7, line 5); and 

decrypting said packets using one of a plurality of decryption keys which allow said data 
receiving means to decrypt said encrypted data and which are updatable, said one of the 
decryption keys being selected in accordance with said encryption key information attached to 
said encrypted data (column 6, line 64 to column 7, line 5, i.e. decryption is done according to 
the IPSec standards 1825-1827). 
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28. Inoue does not teach supplementing the encrypted section with a section header and a 
section trailer, wherein the section header includes a MAC (media access control) header, and 
wherein the padding is filled with a corresponding "1" as a suffix to the data. 

29. It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to fill the padding data with 1 's and add it as a suffix to the data. Since it is padding 
data and is there to act as filler, it is irrelevant what data is actually used to fill the padding 
information. Inoue and the RFC documents disclose the Authentication Header as being in the 
middle of the datagram (see Figures 12B and 12C of Inoue). Relocating the Authentication 
header to the rear of the datagram, thereby making the padding data suffix information to the 
entire datagram, would have required only routine skill in the art since it has been held that the 
mere relocation of a part is not patently distinguishable if it has no bearing on the operation of 
the device. See MPEP § 2144.04; see In reJapikse, 181 F.2d 1019, 86 USPQ 70 (CCPA 1950). 

30. Bhaskaran discloses an encrypted payload (column 2, lines 42-65) that is book-ended by 
a header that includes a MAC header (Figure 3A [clement 320]) and trailer (Figure 3A [element 
360], 3B [elements 320, 380, 390], column 6, lines 26-63). 

3 1 . Bhaskaran also teaches adding transport stream headers to each payload to form packets 
for transmission (Figure 3 A [element 310], column 6, lines 26-49); 

32. It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to supplement the encrypted data section with a section header and trailer, since 
Bhaskaran states at column 6, lines 40-49 that they would eliminate the need to recomputed the 
checksum for every packet, thereby making the network throughput better. Furthermore, IPsec 
can be deployed transparently and without fear of communications being interrupted. 
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33. Inoue and Bhaskaran do not teach transmitting the packets over satellite links. 

34. Willis teaches transmitting packets that have been secured using IPSec over a satellite 
link (Figures 1, 9, column 4, lines 16-25, column 15, lines 33-46, column 16, lines 25-51). 

35. It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to transmit IPsec packets over a satellite link, since Willis states at column 4, lines 23- 
34 that the use of IPsec packets over a satellite link greatly improves the performance of 
transmission while reducing the cost and being secure. 

36. Regarding claim 33, Inouc discloses wherein said plurality of decryption keys include a 
decryption key which is currently usable for decrypting said encrypted data received, and a 
decryption key, encrypted data received; and wherein said data decrypting step selects the 
currently usable decryption key based on said encryption key information (column 12, line 48, 
RFCs 1825, 1826, 1827). 

37. With regards to claim 34, Inoue discloses wherein said encryption key and said 
decryption keys are session keys for encrypting information and data (column 12, line 48, i.e. 
RFC 1825). Section 4.4 of RFC 1825 discloses the use of different session keys for each client 
on the network. 

38. With regards to claims 38 and 39, Inoue teaches wherein said additional information part 
includes data to verify a communication channel (column 12, lines 43-52, i.e. Sections 1.3, 4.3, 
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RFC 1 825 discusses the Authentication Header ensures a trusted subnetwork and trusted 
communication channel). 

39. Claims 25 and 35 are rejected under 35 U.S.C. 103(a) as being unpatentable over Inoue in 
view of Bhaskaran as applied above, and in further view of U.S. Patent No. 6,178,244 Bl to 
Takeda et al, hereinafter Takeda. 

40. Concerning claims 25 and 35, Inoue and Bhaskaran do not teach a data transmission 
controlling, wherein said session keys are updated at predetermined intervals. 

41 . Takeda discloses a data transmission controlling, wherein said session keys are updated 
at predetermined intervals (column 12, lines 38-44). 

42. It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to update the session keys at predetermined intervals, since a skilled artisan would 
realize that it would improve security. By updating session keys at predetermined intervals, it 
makes it more difficult for an eavesdropper to crack encrypted sessions because the keys are 
constantly changing. 

Conclusion 

43. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Christian LaForgia whose telephone number is (571)272-3792. 
The examiner can normally be reached on Monday thru Thursday 7-5. 

44. If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Edan Orgad can be reached on (571) 272-7884. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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45. Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/Christian LaForgia/ 

Primary Examiner, Art Unit 2439 
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